table of contents
- NAME
- DESCRIPTION
- ACCESS CONTROL FILES
- ACCESS CONTROL RULES
- PATTERNS
- WILDCARDS
- OPERATORS
- SHELL COMMANDS
- % EXPANSIONS
- SERVER ENDPOINT PATTERNS
- CLIENT USERNAME LOOKUP
- DETECTING ADDRESS SPOOFING ATTACKS
- EXAMPLES
- MOSTLY CLOSED (ほぼ閉鎖)
- MOSTLY OPEN (ほぼ解放)
- BOOBY TRAPS (ひっかけ罠)
- DIAGNOSTICS
- FILES
- SEE ALSO
- BUGS
- AUTHOR
- 翻訳者
| HOSTS_ACCESS(5) | File Formats Manual | HOSTS_ACCESS(5) |
NAME¶
hosts_access - ホストアクセスコントロールファイルの書式
DESCRIPTION¶
このマニュアルページは、クライアント (ホストネーム/アドレス、ユー ザー名) サーバー (プロセス名、ホストネーム/アドレス) 間の単純な アクセス制御の記述法を解説するものである。具体的な設定例は末尾に 示すので、てっとりばやい設定を望むせっかちな読者は、"設定例" の セクションへと進んで欲しい。
アクセスコントロール書法の拡張された部分に関しては、 hosts_options(5) の文書で解説する。この拡張は、プログラム が -DPROCESS_OPTIONS を指定して作成されたかどうかに左右される。
以下の文章では、daemon とはネットワークデーモンのプロセス 名を意味し、client とは、サービスを要求するホストの名前、 もしくはホストのアドレスを意味している。ネットワークデーモンのプ ロセス名は、inetd の設定ファイル中に明示されている。
ACCESS CONTROL FILES¶
アクセスコントロールのソフトウェアは、二つのファイルを参照する。 最初に一致した時点で検索は終了する。
- (daemon,client) の組合せが /etc/hosts.allow ファイルの中の エントリと一致する場合、アクセスは承諾される。
- もしくは、(daemon,client) の組合せが /etc/hosts.deny ファ イルの中のエントリと一致する場合、アクセスは拒否される。
- それ以外の場合、アクセスは承諾される。
アクセスコントロールのファイルが存在しない場合は、それらのファイ ルが空であったとみなされる。したがって、アクセスコントロールは、 アクセスコントロールファイルを準備しない事によって停止する事がで きる。
ACCESS CONTROL RULES¶
どちらのアクセスコントロールファイルも、0 行以上のテキストで構成 されている。これらの行は出現順に処理される。検索はマッチする行が 現れた時点で終了となる。
- 改行文字は、バックスラッシュが前に置かれた場合は無視される。これ によって、楽に編集するために長い行を分割することが許されている。
- 空行、または `#´ で始まる行は無視される。したがって、コメントを 挿入したり、ホワイトスペースを入れて読みやすく整える事が許されて いる。
- それ以外の行は、次に示すフォーマットに従わなければならない。ただ
し []
で囲まれる部分は任意である:
daemon_list : client_list [ : shell_command ]
daemon_list は、ひとつ以上のデーモンプロセス名 (argv[0] の値) または、ワイルドカード (後述) を使ったリストである。
client_list は、ひとつ以上の、ホスト名、ホストアドレス、ま たは、ワイルドカード (後述) を使った、クライアントのホスト名かア ドレスにマッチするパターンのリストである。
複合化された daemon@host や user@host という形式は、 それぞれ SERVER ENDPOINT PATTERNS および CLIENT USERNAME LOOKUP のセクションで解説する。
リストの各要素は空白、またはカンマで分けなければいけない。
NIS (かつての YP) の netgroup 問い合わせという例外を除いては、 全てのアクセスコントロールのチェックは大文字小文字を同一視して行 なわれる。
PATTERNS¶
アクセスコントロールの書式は以下のようなパターンを満たすものであ る。
- `.' で始まる語。もし、ホスト名の後ろの部分がこの書式で指定され たパターンと一致すると、それはマッチとなる。例えば、`.tue.nl´ というパターンは、`wzv.win.tue.nl´. というホスト名とマッチして いる。
- `.' で終わる語。もし、ホストアドレスの前部の数値フィールドが、 この語と一致するなら、それはマッチしている。例えば、`131.155.´ というパターンは、Eindhoven University network (131.155.x.x)に 属する (ほぼ)全てのホストのアドレスにマッチしている。
- `@´ で始まる語は、NIS (かつての YP) のネットグループ名として扱 われる。もし、ホストがそこで明示されたネットグループ名のメンバー である場合は一致したものとなる。このネットグループのマッチは、デー モンプロセス名やクライアントユーザー名のためにはサポートされてい ない。
- `n.n.n.n/m.m.m.m´ という形式は`net/mask´ の一対として解釈され る。ホストアドレスは、`net´ から見て正ビット方向にあり、かつ `mask´ でマスクされた範囲内にある場合に一致する。たとえば、 net/mask が `131.155.72.0/255.255.254.0´となるパターンは、 `131.155.72.0´ から `131.155.73.255´までの範囲にある全てのアド レスにマッチする。
WILDCARDS¶
アクセスコントロールの書式は、平易なワールドカード群をサポートし ている:
- ALL
- すべてに合致する万能なワイルドカード。
- LOCAL
- ドット文字を持たない全てのホストにマッチ。
- UNKNOWN
- 名前の明らかでないユーザーにマッチ。そして名前
または アド
レスが不明な全てのホストにマッチ。
この形式は注意を持って使用すべきである:ホスト名は、一時的なネー ムサーバーの問題により、使えない場合がありうる。また、ネットワー クアドレスは、ソフトウェアから見て、どんなタイプのネットワークと 会話しているのか、特定できない場合は利用できなくなる。
- KNOWN
- 名前の明らかなユーザーにマッチする。さらに、名前
と アドレ
スの明らかなホストにマッチする。
この形式は注意を持って使用すべきである:ホスト名は、一時的なネー ムサーバーの問題により、使えない場合がありうる。また、ネットワー クアドレスは、ソフトウェアから見て、どんなタイプのネットワークと 会話しているのか、特定できない場合は利用できなくなる。
- PARANOID
- 名前とアドレスの一致しない全てのホストにマッチする。もし tcpd が -DPARANOID (これはデフォルトである) で作成されているなら、アクセ スコントロールテーブルが参照されるより前に、そのようなクライアン トからの要求は落とされてしまう。そのような要求を、さらにコントロー ルしたい場合は -DPARANOID を外して tcpd を構築する事。
OPERATORS¶
- EXCEPT
- 基本的には、次に示すような形式で使用する:
`list_1 EXCEPT list_2´;これは list_2
にマッチするものを除く、
list_1
にマッチするもの全て、に合致する。この
EXCEPT 演算 子は、daemon_lists と
client_lists
の中でも使用できる。EXCEPT
演
算子は、ネスト(入れ子に)して使う事もできる:
もしコントロール書式
が丸括弧を使う事を許可していたなら、`a
EXCEPT b EXCEPT c´は、 `(a EXCEPT (b EXCEPT c))´
と解釈されるであろう。
SHELL COMMANDS¶
もし、最初にマッチしたアクセスコントロールのルールがシェルコマン ドを含んでいるなら、そのコマンドは、%<letter> の置き換え(次のセ クションを参照) があると仮定される。その結果、/bin/sh の子 プロセスが標準入力を伴って実行され、出力とエラーは /dev/null へ送られる。もし、そのプロセスが終了するまで待ち たくない場合には、コマンドの末尾に `&´ が明示すること。
シェルコマンドは、inetd の PATH 設定と関連させてはいけない。代わ りに絶対パスを用いるか、冒頭で明示的に PATH=whatever を宣言する べきである。
hosts_options(5) の文書では、互換性のない異なる方法でシェ ルコマンドのフィールドを使うための、もうひとつの書式を解説してい る。
% EXPANSIONS¶
シェルコマンドの中では下記の拡張表記が利用できる:
- %a (%A)
- クライアント (サーバー) ホストのアドレス。
- %c
- クライアントの情報: user@host, user@address. ホスト名か単にアド レスかは、利用できる情報に依存する。
- %d
- デーモンプロセス名 (argv[0] の値)。
- %h (%H)
- クライアント (サーバー) ホストの名前、もしホスト名が利用できない 場合には、そのアドレス。
- %n (%N)
- クライアント (サーバー) ホストの名前 (もしくは、"unknown" あるい は "paranoid")。
- %p
- デーモンプロセスの id。
- %s
- サーバーの情報: daemon@host, daemon@address, あるいは単にデーモ ンの名前。これは利用できる情報に依存する。
- %u
- クライアントのユーザー名 (もしくは、"unknown")。
- %%
- 文字 `%´ へ展開される。
% の展開が行なわれることによって、シェルを混乱させる可能性のある 文字群は、アンダースコアへと置き換えられる。
SERVER ENDPOINT PATTERNS¶
接続されているネットワークアドレスによって、クライアントを厳密に 区別するためには、以下の形式でパターンを記述する:
process_name@host_pattern : client_list ...
このようなパターンは、マシンが複数の異なるインターネットのホスト 名とインターネットのアドレスを持っている場合に使用する。サービス プロバイダは、異なる組織に属するようなインターネット上の名前を持 つFTP, GOPHER あるいは WWW を提供するために、この機能を利用でき る。hosts_options(5) 文書の中の `twist' のオプションも参照する事。 あるシステム (Solaris, FreeBSD) では、ひとつの物理的なインターフェー スが、複数のインターネットアドレスを持つ事ができる(それ以外のシ ステムでは、専用のネットワークアドレス空間にあるSLIP や PPP など の疑似インターフェースの助けを借りなければならないだろう )。
host_pattern は、client_lists の解説文にあった、ホスト名とアドレ スのような、いくつかの文法に従うことになる。一般的には、server endpoint information (サーバー側末端での情報)は、 connection-oriented serveices (コネクション指向の高いサービス)で のみ利用する事ができる。
CLIENT USERNAME LOOKUP¶
クライアントホストが RFC 931 か、そこから派生したプロトコル(TAP, IDENT, RFC 1413) のどれかをサポートしている場合、ラッパープログ ラムは接続の持ち主に関する、追加の情報を引き出す事が可能である。 クライアントユーザー名の情報が利用可能であるなら、それはクライア ントのホスト名とともに記録され、次のようなパターンにマッチさせる ために使う事ができる:
daemon_list : ... user_pattern@host_pattern ...
デーモンラッパーは、ルールに従う形でユーザー名を探査するように振 舞うか(デフォルト)、あるいは常にクライアントホストに問い合わせる のか、コンパイル時に設定可能となっている。ルールに従う形式でユー ザー名の探査を行なう場合には、上の記述ルールは daemon_list と host_pattern の両方がマッチした場合にのみ、ユーザー名の 探査を行なうであろう。
user_pattern は、デーモンプロセスのパターンと同じ文法であり、す なわち同じワイルドカード群が適用される(ただしネットグループのメ ンバーシップはサポートされない)。しかしながら、これはユーザー名 の探査に独占されるべきではない。
- クライアントのユーザー名に関する情報は、例えばクライアントシステ ムが信用するに足りないものとなっている時には、信頼する事はできな い。一般的には、ALL と (UN)KNOWN は意味のあるユーザー名のパター ンのためにある。
- ユーザー名の探査は TCP ベースのサービスで、そして、クライアント ホストが適切なデーモンを起動している場合にのみ可能である。そして、 それ以外のケースは "unknown" の結果を得る事になる。
- ユーザー名の探査がファイヤーウォールによって阻まれた場合、有名な UNIX カーネルのバグがサービスに損害をもたらすかもしれない。 wrapper の README 文書には、あなたのカーネルに、このバグが存在す るかどうかを調べる手順が紹介されている。
- ユーザー名の探査は、non-UNIX ユーザーに対して行なわれた場合、著 しく遅くなるかも知れない。ユーザー名の探査がタイムアウトで終了す るまでの既定値は10 秒となっている: これは遅いネットワークにとっ ては短すぎるが、PC ユーザーをじらすには充分すぎる。
ユーザー名の探査を選択可能とすることにより、最後の問題を軽減する ことができる。たとえば、こんなルール:
daemon_list : @pcnetgroup ALL@ALL
これはユーザー名の探査を行なわない PC ネットグループのメンバーに もマッチするだろうし、それ以外のシステムに対してはユーザー名の探 査を行なうだろう。
DETECTING ADDRESS SPOOFING ATTACKS¶
多くの TCP/IP の実装に見られる sequence number generator 中の欠 陥は、侵入者が信頼できるホストであることを簡単に装い、例えばリモー トシェルサービスを通して押し入ることを許してしまう。IDENT (RFC931 ほか) サービスはそのようなホストアドレスのペテンによる攻 撃を察知するために使う事ができる。
クライアントの要求に答える前に、TCP ラッパー群は本当のクライアン トが実際には全く要求を送って来ていなかったことを発見する目的で、 IDENT サービスを使う事ができる。
クライアントホストが IDENT サービスを用意しているなら、IDENT の 問い合わせをして、返って来た結果が否定的(クライアントマシンが `UNKNOWN@host') であれば、それはペテン攻撃の確固たる証拠となる。
肯定的な IDENT の問い合わせ結果 (クライアントマシンは `KNOWN@host')でも、充分に信頼できるとは言い切れない。単にクライ アントのコネクションを誤魔化すよりは難しいが、それでも侵入者はク ライアントのコネクションと、IDENT の問い合わせの両方を偽っている 可能性がある。さらには、クライアントの IDENT サーバーそのものが 嘘をついていることさえ考えられる。
Note: IDENT の問い合わせは UDP サービスと共存して動作する事はできない。
EXAMPLES¶
文法は最小限の苦労で、さまざまなタイプのアクセスコントロールが表 現可能な、柔軟なものである。この文法は二つのアクセスコントロール のリストが必要なのだが、身もフタもない方策としては、片方のリスト を極めて単純なものとするか、空にしておくことが挙げられる。
以下の記述例を読むにあたっては、allow の記述は deny の記述より先 に検索され、その検索は最初にマッチしたもので終了となり、マッチし たものが全く見つからない場合には、アクセスは承認される、というこ とをはっきりと理解しておくことが重要である。
記述例はホストとドメインの名前を使う。ネームサーバーへの問い合わ せが一時的に失敗した場合の影響を軽減するためには、これらにアドレ ス、かつ、あるいは network/netmask の情報を含めることで、改善す る事ができる。
MOSTLY CLOSED (ほぼ閉鎖)¶
この場合、アクセスはデフォルトで拒絶される。明示的に権限を授けら れたホストのみがアクセスを許される。
デフォルトのポリシー(no access)は、単に deny file の中で記述され る:
/etc/hosts.deny:
ALL: ALL
これによって、allow file の中のエントリでアクセスが許可されない 限り、全てのホストへのサービスは拒否となる。
明示的に権限を授けるホストは、allow file の中でリストされる。記 述例:
/etc/hosts.allow:
ALL: LOCAL @some_netgroup
ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
最初のルールでは、ローカルドメイン(ホスト名に `.´を必要としない) と、some_netgroup に属するホストからのアクセスが許可されて いる。二番目のルールでは、terminalserver.foobar.edu. を除 くfoobar.edu ドメイン(ドットで始まることが宣言されている) の、全てのホストからのアクセスが許可されている。
MOSTLY OPEN (ほぼ解放)¶
明示的にサービスを拒否するホストを除き、アクセスはデフォルトで許 可となる。
デフォルトのポリシー(access granted) に従えば、どんな allow file でも、まったく省略可能なほど冗長なものとなる。明示的に権限を与え ないホストは、deny file にリストする。記述例:
/etc/hosts.deny:
ALL: some.host.name, .some.domain
ALL EXCEPT in.fingerd: other.host.name, .other.domain
最初のルールでは、いくつかのホストと、ドメインへの全てのサービス が拒否される。二番目のルールでは、それ以外のホストとドメインから の finger リクエストに限って許可が与えられている。
BOOBY TRAPS (ひっかけ罠)¶
次のサンプルはローカルドメインのホスト(ドットで始まる事が宣言さ れている)からの tftp リクエストを許可するものである。それ以外の ホストからのリクエストは拒否される。そして要求されたファイルの代 わりに、finger の探り針がその無礼なるホストへと放たれる。結果は スーパーユーザーへメイルで送られる。
/etc/hosts.allow:
in.tftpd: LOCAL, .my.domain
/etc/hosts.deny:
in.tftpd: ALL: (/some/where/safe_finger -l @%h | \ /usr/ucb/mail -s %d-%h root) &
safe_finger コマンドは tcpd wrapper に付属しており、適切な場所に インストールされるべきである。これはリモートの finger サーバーか ら送られてくるデータによってダメージが与えられる可能性を制限して る。これは標準の finger コマンドよりも優れた防御をもたらす。
%h (client host) と %d (service name) の展開については、shell commands のセクションで解説されている。
警告: finger の無限ループへの対処ができないなら、あなた自身の finger デーモンに対して、この booby-trap (引っかけ罠) を仕掛けな い事。
ネットワークファイヤーウォールにおいては、このトリックはさらに大
幅に拡張することができる。典型的なネットワークファイヤーウォール
は、外部に対して限定されたサービスしか提供しない。それ以外のサー
ビスは、上記の tftp
の例のように
"盗聴"
することができる。その結
果、極めて優れた早期警戒装置となる。
DIAGNOSTICS¶
以下の場合にエラーが報告される。ホストコントロールファイルに文法 エラーが見つかった場合。アクセスコントロールのルールの長さが内部 のバッファの容量を越えた場合。アクセスコントロールのルールが、改 行文字によって終わっていない場合。%<letter> 展開の結果、内部バッ ファが溢れてしまった場合。期待に反して、システムコールが失敗した 場合。すべての問題は、syslog デーモンを通じて報告される。
FILES¶
/etc/hosts.allow, アクセスを許可する (daemon,client) のペア。 /etc/hosts.deny, アクセスを拒否する (daemon,client) のペア。
SEE ALSO¶
tcpd(8) tcp/ip daemon wrapper プログラム tcpdchk(8), tcpdmatch(8), test programs.
BUGS¶
ネームサーバーの問い合わせがタイムアウトとなると、ホスト名は、た とえ登録されていても、アクセスコントロールソフトからは利用できな い。
ドメインネームサーバーの問い合わせは、大文字小文字を同一視する。 一方 NIS (かつての YP) のネットグループは、大文字小文字を区別す る。
AUTHOR¶
Wietse Venema (wietse@wzv.win.tue.nl) Department of Mathematics and Computing Science Eindhoven University of Technology Den Dolech 2, P.O. Box 513, 5600 MB Eindhoven, The Netherlands
翻訳者¶
FUKUSHIMA Osamu/福島於修 <fuku@amorph.rim.or.jp>